In messaging systems, the use of messages and message queues in a wider network provide an asynchronous communications protocol, which means that the sender and receiver of a message do not need to interact with a message queue at the same time. Messages placed onto a queue are stored until a recipient retrieves them. Such networks support the passing of messages between different computer systems, connecting multiple applications and multiple operating systems. Messages can also be passed from queue to queue in order for a message to reach the ultimate desired recipient. An example of a commercial implementation of such messaging software is IBM's WebSphere MQ (previously MQ Series).
In a synchronous communication protocol, one system connects to another system, sends a request and waits for a reply. In many situations this is the ideal method of communicating. For example, a user sends a request for a web page and then waits for a reply. However, other systems exist in which such behaviour is not desirable. For example, an application may need to notify a different application that an event has occurred, but does not need to wait for a response. Another example occurs in publish/subscribe systems, where an application publishes a message for any number of clients to read. In both these examples it would not make sense for the sender of the information to have to wait for a reply, if, for example, one of the recipients had crashed.
Alternatively, an application run by a website, such as an online store, may need to respond to certain parts of a request immediately (such as telling the user that a purchase has been accepted), but may queue other parts (such as the calculation of invoice amounts and the forwarding of data to the central accounting system, and so on) to be done some time later. In all these sorts of situations, having at least a subsystem which does asynchronous message queuing can help improve the performance of the overall system.
One way messages may be sent reliably and, using a transactional queuing system, may be sent as part of the requesting application's transaction. On the receiving side, a message may be received and executed as part of a separate transaction. Existing messaging systems support assured message “delivery” for asynchronous and time-independent one way communication between an application source and an application destination. Such a facility accommodates the possibilities of link failure and many other conditions that can arise in complex networks.
The receiver need not be available when a message is transmitted by the source and the communication path the message traverses may be across different execution environments (therefore traditional distributed atomic transactions are not appropriate for messaging). A typical model is that there are three participants, the message source, the messaging service and message receiver, each in a different transaction, with the messaging service middleware taking responsibility for delivering the messages reliably between transactions.
Each participant may be doing other work, for example, performing database I/O, dealing with other messages or even taking part in a distributed synchronous transaction with other servers. Typically the message source places a message on a queue, and it is sent when the transaction is committed (i.e. the source hands the message to the transactional messaging service and when the message source commits the transaction the messaging service “persists” the message to be delivered to the receiving target so that it can be reliably delivered across any failure of the transport). The messaging service provider logically has a transaction that includes receiving the message from a persistent queue and placing the message on a queue designated for the message receiver. Finally, the message receiver (which may or may not be the message source) performs a transaction that includes retrieving the message from a queue and processing the contents of the message (which might involve executing a business service). Such a method of operation is known as an ‘unshared-transaction’ between message source and message receiver.